NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/sys/amiga/programmer/796

Internet Message Format | 1996-08-05 | 5.5 KB

Path: cs.uwa.edu.au!jasonb
From: [e-mail] (Jason S Birch)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: PPC compilers
Date: 11 Jan 96 14:44:28 GMT
Organization: The University of Western Australia
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <VBzVx*[e-mail]> <4d0tf0$[e-mail]>
NNTP-Posting-Host: decadence.cs.uwa.oz.au
X-Newsreader: NN version 6.5.0 #3 (NOV)

[e-mail] (Stephan Schaem) writes:

>Arno Eigenwillig ([e-mail]) wrote:
>: Don't distract, this was not the point. Intentional misunderstandings
>: prove nothing.

> It was about: "C is better because you dont need to know your variable type"

No, it wasn't, which is what I've been repeatedly saying. It was about
whether assembler is easier to debug than C because the line:

move.w (a0)+,(a1)+

tells you how many bytes are being moved, and added to a0 and a1,
whereas:

*a++ = *b++;

does not. Many of us said "no", not least because the assembler line
doesn't tell you whether you *wanted* to move two bytes or not unless
you know what a0 and a1 are pointing to. You need to know that to know
if it's correct, just as you need to know that *a and *b are the same
type, although in the C case you *don't* need to know how many bytes
are moved or added to a and b - you don't need to know how the types
are *implemented*, and the claim was made that, in any case, you could
pretty much rely on C to complain if you make a mistake. This is where
you came in. Note the difference between "not needing to know your
variable type" and "not needing to know how that variable type is
implemented on a particular hardware/OS/compiler implementation".

>: What are you talking about? <time.h> is provided as part of the
>: compiler. The compiler is a beast that translates a valid C source
>: code defining an algorithm for an abstract machine into actual machine
>: code for an actual machine.

> I'm talking about doing operation on a strcuture element. if the element
> was defined has a ulong, then one decide its a float you will have to
> update your code too to use float.

This is a red herring. If the *type* of an element in a structure is
given as ulong, then it must be a ulong, it is bound to being a ulong,
and you can forever more treat it as a ulong. If it's given as a
bilby, however, and somewhere else a bilby is defined to be a ulong
(via typedef), then it is only bound to being a bilby and you can only
treat it like a bilby - you may not treat it as a ulong.

Note well, however, that even ulong is an abstract type, and the only
assumptions you can make about it are those guaranteed by ANSI
(assuming you want portability, of course). In particular, it is *not*
guaranteed to be a 32 bit unsigned integer. On a DEC Alpha, for
example, it's 64 bits. On a 16 bit machine, it could well be 16 bits.
Look at integer for another example - on a 68000 Amiga with SAS/C, it
defaults to 32 bits; specify SHORTINTEGERS and it's 16 bits. On a Mac,
it's 16 bits. Win16 code on a PC, it's 16 bits; compile for Win32 and
it's 32 bits. The reason for not specifying these sizes is efficiency
- leaving them undefined allows the compiler writer to choose the most
efficient representation. Unfortunately, it requires the programmer to
do more work to make sure the types can hold the values required. It
would make writing portable code easier if there were int16, int32,
int64, etc, types, but this is a side issue. :-)

>: Then there is clock_t (and similar beasts like size_t, prtdiff_t).
>: clock_t is a typedef for one out of a set of simple types, but it is
>: not said which one. Again, there are objects of type clock_t and
>: operations defined for them with specific semantics.

> I dont rememner reading clock_t was a type of type ulong...

From SAS/C's time.h:
typedef unsigned long clock_t;

However, it doesn't matter.

>: The idea behind clock_t is that it is a data type suitable for storage
>: of the system's clock's value and certain operations on it. These
>: operations are defined in an abstract way, independant of a specific
>: choice what simple type clock_t may actually be.

> you might not care clockt_t went from 32bit long to a 64bit long,
> but I you would if it become a 32digit bcpl.

It couldn't, because "-" would no longer work; however, if a
DiffClock() function existed, it could. time_t is a better example.

>: The obvious advantage is that these conception of the abstract machine
>: allows C source code to be portable to many different actual machines,
>: no matter what strange encoding they use for clock_t.

> No matter what strnage encoding... how about a pointer to a string?

Again, time_t is a better example. clock_t must be an ordinal type.

>: Dave called it "polymorphism". I call it "data encapsulation". Anyway,
>: it's a basic concept of decent programming, and not having understood
>: it is no crime, but one probably shouldn't go around demonstrating it
>: everywhere in the most embarrassing way. Eh?

> The point he wanted to prove is that you dont need to care about your
> variable type, and your variable type definition. I just desagree.

This is the problem - he never wanted to prove that. You misinterpreted
his comments, and have thus far refused to give up your straw man. :-)

> Stephan

--
Jason S Birch                        ,-_|\ email: [e-mail]
Department of Computer Science      /     \ Tel (work): [phone]
The University of Western Australia *_.-._/ Fax (work): [phone]
Nedlands  W. Australia  6907             v  Tel (home): [phone]